Apparatus, system, and method for sharing and accessing data by scopes

ABSTRACT

An apparatus, system, and method are disclosed for scoped management of software objects. The apparatus includes a receive module, an establish module, and a control module. The receive module receives a request to access a scoped resource. The establish module establishes access to the scoped resource accessible by a plurality of independent objects based on a specified scoping scheme. The control module controls access to the scoped resource in accordance with the specified scoping scheme. Additionally, the apparatus may provide an API for a scoping service. The apparatus, system, and method reduce errors and unexpected results in modular software design in a J2EE software environment as well as other software environments in which modular software design is used.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to management of software and data resources in acomputing environment and more particularly relates to sharing andaccessing data by scopes.

2. Description of the Related Art

Software technology continues to improve. With recent advances in thefields of web programming, data storage systems, personal computers andelectronics, and computer networking, associated software programming isbecoming more and more complex. One solution to help reduce thecomplexity of software programming is the adoption of object-orientedand component-based development methodologies. In object-oriented andcomponent-based development a large software code is broken up intosmaller objects, components and modules. These smaller portions of thecode are self-contained in some instances, and used as building blocksto develop a larger software system. The smaller units are assembled,packaged and deployed to support the composition of multiplatform,multilayer, and multifunction system. Separate handling of softwareunits creates additional complexity in sharing resources such asin-memory data as well as external objects among the deployment units.

FIG. 1 illustrates a common computing environment. Multiple softwarehosts or application servers, may be networked together to form acluster. These clustered application servers may share applicationresources one to another. One application server may host multipleapplications. Typically, an application is a composite of multiplemodules, each module possibly containing multiple components.Applications are written in a modular format to simplify many aspects ofsoftware design. For example, if a developer breaks up an applicationinto modules or components, he needs only to focus on one smallerportion of the application at a time. Another benefit of modularity isthe ability to allow multiple developers to work on the applicationsimultaneously.

One drawback of modular applications is the complexity of the finalarchitecture. In some cases, a single application may include severallayers of modules and components. For example, an application developedin Java 2 Enterprise Edition (J2EE) may include one or more modules. Themodules can be Web modules, EJB modules, Client modules or ResourceAdapter modules. Each module may include one or more components such asServlets, JSP pages, Enterprise Java Beans (EJBs), and the like.Consequently, it becomes necessary to define the scope of each elementof the computing system, and determine guidelines for sharing resourcesaccording to compatible scopes.

For example, in a J2EE environment, an application server may host anapplication containing two components in a module. A hit counter isrequired for each component to record the number of hits on thecomponent. The counter object is shared among all the instances of thatcomponent and it is desirable that each component keeps its own counterobject without interference from the other. A common implementationtechnique may keep the counter as a class variable (i.e., a static fieldof a java class or interface) of Counter class. If the Counter class ispackaged in the application, the isolation can be broken and it turnsout that the two components share the same counter. When the firstcomponent accesses the counter object, it may encounter unexpectedvalues due to the modifications made to shared variable by the secondcomponent.

In another example, multiple objects may need to share informationbetween the objects. However, in J2EE a separate class loader may loadeach object. If the variable that needs to be shared is declared staticor local, each instance of the object may only locally modify thevariable. For example, two separate web applications may request accessto a hit counter object, and specifically to the counter variable of thehit counter object. The web applications need to increment the same hitcounter for. If two separate class loaders load the hit counter class,and the counter variable of the hit counter object is declared static,the applications may increment the counter variable of the localinstance of the hit counter object, but not share access to the countervariable with the other web object.

In another example, software activity based scoping issues may arise.These may be considered horizontal scoping issues, because the typicalhierarchical structure does not apply. For example, an activity, athread, a transaction, an Hypertext Transfer Protocol (HTTP) session, orthe like are considered to by activity oriented. An HTTP session may becreated to handle certain web activities. However, some activities mayrequire separate HTTP sessions. If a web application performs certainactivities on a web page, but a user requests the application to performactivities that require a new web page, an new HTTP session may berequired. In this situation, horizontal scoping is required.

The problems highlighted in the examples above may be amplified in theJ2EE environment. Unlike its predecessor Java 2 Standard Edition (J2SE),J2EE utilizes multiple class loaders to access software resources. Oneapplication, module, or other component may access a shared resourcewith its class loader, while a second class loader accesses the sameshared resource (i.e., the global variable of the scoped singleton). Thefirst component may not have information regarding actions taken by thesecond component on the shared resource. Alternatively, two parentobjects may desire shared access to a variable, but only get localaccess to the variable because the J2EE class loaders have createdseparate instances of the object and associated static or localresource. Therefore, the first and the second components may encountererrors or unexpected results because an object may include staticattributes shared between multiple instances of the object.

As a workaround in J2EE, some scoping between objects may be achieved bycareful deployment, packaging, and class loader delegation. Scopeddeployment includes limiting object deployment to a predefinedhierarchical order. For example, if a class variable is to be shared bymultiple applications running on the same JVM, the class has to bedeployed to the class path of an ancestor class loader of all theapplication class loaders.

To support the packaging and deployment model, a J2EE server typicallyuses a hierarchy of class loaders to load classes from differentdeployment units. The classes used by an application can be loaded bydifferent class loaders in the hierarchy. This aspect of J2EE createsvisibility issues at java class level for sharing information amongcomponents across deployment units. The class loader delegation modelcreates scopes for sharing and isolation, however the developers mustpredetermine the delegation architecture. Such a task may beinordinately time consuming, and intellectually challenging. Typicaldevelopers of ordinary skill in the art are not concerned with theintricacies associated with class loader delegation.

Unfortunately, implementation of effective scoping in complicatedapplications may be difficult or even impossible. Currently two optionsfor scoping exist. Either the developer must define, package, andproperly deploy separate instances of each resource to be used within adifferent scope relying on the class loader hierarchy and delegationmodel, or implement a custom designed set of objects and methods toassociate scope with instantiated objects.

These custom designed solutions tend to be particularly suited to ascoping scheme specific to the scoping problems faced by a developer.Another difficulty associated with the scoping solutions described aboveis the limited application of each solution. The solutions typically arespecific to a single scoping goal. Therefore, the scoping solutions maynot apply to every situation in which software object scoping isdesirable. It would be useful to provide a scoping framework broadenough to apply to a wide variety of development and runtimeapplications. Additionally, it would be useful to provide flexiblecustomization of scoping as a plug-in feature of the framework.

From the foregoing discussion, it should be apparent that a need existsfor an apparatus, system, and method that provide scoped management forsoftware objects. Beneficially, such an apparatus, system, and methodwould reduce scope related errors, simplify scoped data sharing andaccess by providing a broadly applicable, and highly flexible scopingservice.

SUMMARY OF THE INVENTION

The present invention has been developed in response to the presentstate of the art, and in particular, in response to the problems andneeds in the art that have not yet been fully solved by currentlyavailable software platforms. Accordingly, the present invention hasbeen developed to provide an apparatus, system, and method for scopedmanagement of software objects that overcome many or all of theabove-discussed shortcomings in the art.

The apparatus for scoped management of software objects is provided witha logic unit containing a plurality of modules configured tofunctionally execute the necessary steps of receiving a request toaccess a scoped resource, establishing access to the scoped resourceaccessible by a plurality of independent objects based on a specifiedscoping scheme, and controlling access to the scoped resource inaccordance with the specified scoping scheme. These modules in thedescribed embodiments include a receive module, an establish module, anda control module.

In one embodiment, the apparatus is configured to receive a request toaccess a scoped resource. The apparatus may include an interface moduleconfigured to provide an Application Program Interface (API) forassociating a scope with a software object. Additionally, an extendmodule may add one or more scoping schemes dynamically to the apparatusas a plug-in.

In one embodiment, the establish module establishes access to the scopedresource accessible by a plurality of independent objects based on aspecified scoping scheme. In one embodiment, the apparatus includespre-defined scoping schemes that implement common scoping requirements.The specified scoping scheme may include a hierarchical scoping scheme.Alternatively, the specified scoping scheme may include a horizontalscoping scheme. In another embodiment, the establish module may includea lifecycle module configured to manage a scope lifecycle, wherein thelifecycle of the scope is determined by lifecycle events triggered by anaction of a calling object.

In one embodiment, the control module controls access to the scopedresource in accordance with the specified scoping scheme. The controlmodule may include a management module configured to manage resourcesshared by the plurality of independent objects according to policiesdefined in the specified scoping scheme. In one embodiment, themanagement module includes an access module configured to access sharedinformation in response to the request from objects, each object havinga scope that satisfies the specified scoping scheme. The softwareobjects that share the scoped resource may comprise compatible scopes.

A system of the present invention is also presented for scopedmanagement of software objects. In one embodiment, the system includesan application server, one or more software objects, and a scopeservice. In one embodiment, the application server is configured to hostone or more software objects. The software objects may access a scopedresource. Additionally, the scope service receives a request to access ascoped resource, establishes access to the scoped resource accessible bya plurality of independent objects based on a specified scoping scheme,and controls access to the scoped resource in accordance with thespecified scoping scheme.

A method of the present invention is also presented for scopedmanagement of software objects. The method in the disclosed embodimentssubstantially includes the steps necessary to carry out the functionspresented above with respect to the operation of the described apparatusand system. In one embodiment, the method includes receiving a requestto access a scoped resource, establishing access to the scoped resourceaccessible by a plurality of independent objects based on a specifiedscoping scheme, and controlling access to the scoped resource inaccordance with the specified scoping scheme.

These features and advantages of the present invention will become morefully apparent from the following description and appended claims, ormay be learned by the practice of the invention as set forthhereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsthat are illustrated in the appended drawings. Understanding that thesedrawings depict only typical embodiments of the invention and are nottherefore to be considered to be limiting of its scope, the inventionwill be described and explained with additional specificity and detailthrough the use of the accompanying drawings, in which:

FIG. 1 is a conceptual diagram illustrating a layered softwareenvironment;

FIG. 2 is a schematic block diagram illustrating one embodiment of asystem for scoped management of software objects;

FIG. 3 is a schematic block diagram illustrating one embodiment of anapparatus for scoped management of software objects;

FIG. 4 is a detailed schematic block diagram illustrating one embodimentof an apparatus for scoped management of software objects;

FIG. 5 is a schematic flow chart diagram illustrating one embodiment ofa method for scoped management of software objects;

FIG. 6 is a detailed schematic flow chart diagram illustrating oneembodiment of a method for scoped management of software objects;

FIG. 7 is a conceptual diagram illustrating one example of ahierarchical scoping scheme.

DETAILED DESCRIPTION OF THE INVENTION

Many of the functional units described in this specification have beenlabeled as modules, in order to more particularly emphasize theirimplementation independence. For example, a module may be implemented asa hardware circuit comprising custom VLSI circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A module may also be implemented in programmablehardware devices such as field programmable gate arrays, programmablearray logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by varioustypes of processors. An identified module of executable code may, forinstance, comprise one or more physical or logical blocks of computerinstructions which may, for instance, be organized as an object,procedure, or function. Nevertheless, the executables of an identifiedmodule need not be physically located together, but may comprisedisparate instructions stored in different locations which, when joinedlogically together, comprise the module and achieve the stated purposefor the module.

Indeed, a module of executable code may be a single instruction, or manyinstructions, and may even be distributed over several different codesegments, among different programs, and across several memory devices.Similarly, operational data may be identified and illustrated hereinwithin modules, and may be embodied in any suitable form and organizedwithin any suitable type of data structure. The operational data may becollected as a single data set, or may be distributed over differentlocations including over different storage devices, and may exist, atleast partially, merely as electronic signals on a system or network.

Reference throughout this specification to “one embodiment,” “anembodiment,” or similar language means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention. Thus,appearances of the phrases “in one embodiment,” “in an embodiment,” andsimilar language throughout this specification may, but do notnecessarily, all refer to the same embodiment.

Reference to a signal bearing medium may take any form capable ofgenerating a signal, causing a signal to be generated, or causingexecution of a program of machine-readable instructions on a digitalprocessing apparatus. A signal bearing medium may be embodied by atransmission line, a compact disk, digital-video disk, a magnetic tape,a Bernoulli drive, a magnetic disk, a punch card, flash memory,integrated circuits, or other digital processing apparatus memorydevice.

The schematic flow chart diagrams included are generally set forth aslogical flow chart diagrams. As such, the depicted order and labeledsteps are indicative of one embodiment of the presented method. Othersteps and methods may be conceived that are equivalent in function,logic, or effect to one or more steps, or portions thereof, of theillustrated method. Additionally, the format and symbols employed areprovided to explain the logical steps of the method and are understoodnot to limit the scope of the method. Although various arrow types andline types may be employed in the flow chart diagrams, they areunderstood not to limit the scope of the corresponding method. Indeed,some arrows or other connectors may be used to indicate only the logicalflow of the method. For instance, an arrow may indicate a waiting ormonitoring period of unspecified duration between enumerated steps ofthe depicted method. Additionally, the order in which a particularmethod occurs may or may not strictly adhere to the order of thecorresponding steps shown.

Furthermore, the described features, structures, or characteristics ofthe invention may be combined in any suitable manner in one or moreembodiments. In the following description, numerous specific details areprovided, such as examples of programming, software modules, userselections, network transactions, database queries, database structures,hardware modules, hardware circuits, hardware chips, etc., to provide athorough understanding of embodiments of the invention. One skilled inthe relevant art will recognize, however, that the invention may bepracticed without one or more of the specific details, or with othermethods, components, materials, and so forth. In other instances,well-known structures, materials, or operations are not shown ordescribed in detail to avoid obscuring aspects of the invention.

FIG. 2 depicts one embodiment of a system 200 for scoped management ofsoftware objects including applications, components, EJBs, and the like.The system 200 may include an application server 202, one or moresoftware objects 204 a-b, a scope service 206, a scope resource 208, anda scoping scheme 210. In one embodiment, the application server 202 isconfigured to host one or more software objects 204, the softwareobjects 204 may be configured to access a scoped resource 208, and thescope service 206 may facilitate scoped access to the scoped resource208 according to a specified scoping scheme 210.

In certain embodiments of the system 200, a plurality of applicationservers 202 may comprise a cluster of application servers 202. Thecluster may have an associated scope, and each application server 202may have a different associated scope. In one embodiment, a scopeincludes an operating environment within which variables and objectsexist and may be shared between software callers and objects accordingto a scoping scheme. Scope, as used herein, includes a characteristic ofa resource 208 that describes where the resource 208 may be used inrelation to other resourses, and what other elements of the system mayaccess the resource 208. In one embodiment, the scope may comprise thenamespace of a variable. In another embodiment, the scope may comprise adomain in which a resource 208 operates, or is operated upon.

Information regarding the scope of a scoped resource 208 may bedescribed in a scoping scheme 210. The scoping scheme 210 may define ascoping strategy, scoping policies, a list of resources to be groupedinto a scope, sharing policies, and the like. In one embodiment, thescope may be defined by the class of the resource. In anotherembodiment, the scope may be defined by the structure of the callinghierarchy. Alternatively, the scope may be defined by the activity to beperformed by the resource. Additional embodiments of a scope and scopingscheme may be defined in pluggable scoping schemes 210 and implementedby the scope service 206.

A scoping scheme 210 may include a listing of policies and commandsrequired to implement a specified scope. For example, a scoping scheme210 may call functions or modules required to launch an instance of anobject within a specified scope, store shared data within a specifiedscope, and the like. In one embodiment, the application server 202defines a scope comprised of applications, objects, and variablesdefined as public or static which can be accessed by other applications,objects, or variables of the same scope.

In one embodiment, one or more software objects 204 may be configured toaccess a scoped resource 208. In one embodiment, a software object 204is an application, module, function, component, or the like. In anotherembodiment, the software object 204 may include J2EE components. Forexample, a software object 204 may include a JVM, an EJB, a web servlet,and the like. In certain embodiments, the software object 204 may accessa scoped resource 208. Additionally, the software object 204 may passscoping information as a parameter in a scoped resource call. Forexample, a J2EE application may call an EJB to perform a task on behalfof the application. The EJB call may include the name of the EJBinstance, and the appropriate scope for the EJB instance.

In one embodiment, a scoped resource 208 is data stored by any softwareobject, instance, or variable a developer intends to make available foraccess to other software code such as a software object 204 a. A scopedresource 208 may include data stored by an application, a module, asoftware component, a function, a software service, a data element, orthe like. The scoped resource 208 is scoped so that access to theresource 208 can be controlled according to a scoping scheme 210. Ascoping scheme 210 defines rules by which a caller within a first scopecan access a scoped resource 208 of the same or different scope.

In one embodiment the scope service 206 receives a request to access ascoped resource 208 from a software object 204 a. The request mayinclude parameters such as the name and scope of the desired scopedresource 208. Additionally, the scope service 206 may establish accessbetween the software object 204 a and the scoped resource 208. The scopeservice 206 may also control access to the scoped resource in accordancewith a specified scoping scheme 210. The scoping scheme 210 may comprisea default scoping scheme or a user defined scoping scheme. Additionalembodiments of the scope service 206 shall be discussed in detail withreference to FIG. 3 and FIG. 4.

FIG. 3 illustrates one embodiment of an apparatus 300 for scopedmanagement of software objects. The apparatus 300 may include a receivemodule 302, an establish module 304, and a control module 306. In oneembodiment, the apparatus 300 implements scope policies on scopedresources 208 as defined by a scoping scheme 210. The apparatus 300 mayimplement part of a scope service 206 to interface between a callingsoftware object 204 and a scoped resource 208.

In one embodiment, the receive module 302 receives a request to access ascoped resource 208. The request may originate from a software object204 calling the scoped resource 208 to perform a predetermined task. Inone embodiment, the request is a method or function call includingmultiple parameters. The parameters may include the name of the scopedresource 208 called, and the name of the scoping scheme 210 to beapplied to the resource 208. Additionally, the receive module 302 mayidentify the location of the scoping scheme 210 to apply to the scopedresource 208 by cross-referencing a list of scoping scheme filelocations mapped to scoping scheme names. In one embodiment, the scopingscheme name map may be stored in a registry of scoping schemes.

In one embodiment, the establish module 304 may establish access to ascoped resource 208. The scoped resource 208 may be accessible bymultiple independent objects based on a specified scoping scheme 210. Inone embodiment, the establish module 304 applies scoping policies to thescoped resource 208 when an instance of the scoped resource 208 iscreated. In one embodiment, the establish module 304 may create aninstance of an object that stores a scoped resource 208, by authorizinga class loader of a specified scope to load an instance of the softwareobject that includes a scoped resource 208 accessible by otherindependent scoped objects in accordance with scoping policies definedby the scoping scheme 210. In other words, the establish module 304associates the scope of the class loader with that of the object andassociated scoped resources 208. Consequently, references to the scopedresource 208 can be controlled by reviewing the scope of the scopedresource 208 in relation to the scoping scheme 210.

For example, a J2EE class loader for an application may create aninstance of an EJB to be used within the scope of the application.Additionally, certain modules within the application may be restrictedfrom accessing the EJB. In such an example, the application representsthe software object 204, the EJB includes the scoped resource 208, andthe apparatus 300 may establish access by the application 204 a to theEJB 208 according to a specified scoping scheme 210. In such an example,the scoping scheme 210 may be a hierarchical scoping scheme 210.

In one embodiment, the apparatus 300 may include pre-defined scopingschemes that implement common scoping requirements. In one embodiment,the pre-defined scoping scheme is a hierarchical scoping scheme thatimplements scope assignments according to a chain of callers, logicalsoftware layers, and the like. For example, a hierarchical scopingscheme may follow an application server, application, module, component,attribute, data priority layout according to the hierarchy of theobjects in descending order.

Alternatively, a pre-defined scoping scheme may include a horizontalscoping scheme. The horizontal scoping scheme may define scopingpolicies based resource activities instead of the organizationalstructure of the software objects 204. Activities may includetransactions, threads, sessions, HTTP sessions, HTTP requests, databaserequests, and the like. Additional scoping schemes may exist asdescribed in relation to FIG. 4.

Once the establish module 304 establishes access to the scoped resource208, the control module 306 continues to control access to the scopedresource 208 by restricting access by software objects 204 a-b of anincompatible scope, and allowing access by software objects 204 a-b of acompatible scope (See FIG. 2). In one embodiment, the control module 306may control which software objects 204 selected from a group of softwareobjects may access the scoped resource 208. Additionally, the controlmodule 306 may control data storage with respect to the scoped object.For example, the control module 306 may control where informationgenerated by interactions between the scoped resource 208 and thesoftware object 204 is stored.

In another example, the control module 306 may control when a newhorizontal scope of an activity based scoped resource 208 needs to becreated. In such an example, a scoped resource 208 may be defined by atransaction, thread, session, or the like. A new transaction, thread, orthe like may be required in response to certain conditions defined inthe specified scoping scheme 210. One example of a horizontal scopingscheme may include an HTTP session. Certain web pages, web servlets andthe like maybe accessed within the scope of one HTTP session. However,calls to certain web pages or web servlets may require a new HTTPsession to be established. Such determinations may be controlled by thecontrol module 306 as defined by the policies of the specified scopingscheme 210.

FIG. 4 illustrates one detailed embodiment of an apparatus 400 forscoped management of software objects. In addition the receive module302, the establish module 304, and the control module 306 as describedin relation to FIG. 3, the apparatus 400 may include an interface module402, an extend module 404, a lifecycle module 406, a management module408, and an access module 410. In certain embodiments, the describedmodules may be utilized in a software runtime environment.Alternatively, certain modules may be utilized in a software developmentenvironment.

In one embodiment, the interface module 402 provides an ApplicationProgram Interface (API) for associating a scope with a software object.The interface module 402 may allow software objects 204 a-b (See FIG. 2)to establish scoped access to a scoped resource 208 by making a requestto the apparatus 400. In one embodiment, the apparatus 400 comprises ascope service 206. In one example, the scope service 206 may be aservice managed by a J2EE container. In certain embodiments, theinterface module 402 may require a software object 204 to call a scopedresource 208 using a predefined calling command structure.

In one embodiment, the extend module 404 adds one or more scopingschemes dynamically to the apparatus 400 as a plug-in. The extend module404 may allow software users and developers to customize therelationship between scope of resources 208 and software objects 204using pluggable scoping scheme files. In one embodiment, the extendmodule 404 may accept custom scoping information defined in ExtensibleMarkup Language (XML) files. Alternatively, the scoping information maybe defined in text files, graphical user interfaces (GUIs), stored dataconstructs, and the like. The extend module 404 may accept scopinginformation defined in the scoping scheme files, and map the scopingscheme file to a scoping scheme name. In an alternative embodiment, thescoping scheme files may be added via the extend module 404 dynamicallyat run time of an application. For example a customizable scoping schememay be configured to support persistent data storage or highavailability within a scope. For example, a pluggable XML scoping schemefile may include the following: <?xml version=“1.0” encoding=“UTF-8”?><schema targetNamespace=“http://www.ibm.com/xmlns/prod/websphere/sis/”xmlns=“http://www.w3.org/2001/XMLSchema”xmlns:sis=“http://www.ibm.com/xmlns/prod/websphere/sis/”> <elementname=“scoping” type=“sis:Scoping” /> <complexType name=“Scoping”><sequence> <element name=“scheme” type=“sis:Scheme” minOccurs=“0”maxOccurs=“unbounded” /> </sequence> </complexType> <complexTypename=“Scheme”> <attribute name=“name” type=“NMTOKEN” /> <!-- The name ofthe scoping scheme --> <attribute name=“managerClass” type=“NMTOKEN” /><!-- The name of the ScopeManager impl class --> <attributename=“storeClass” type=“NMTOKEN” use=“optional” /> <!-- The name of theContextStore impl class --> </complexType> </schema> <?xml version=“1.0”encoding=“UTF-8”?> <sis:scopingxmlns:sis=“http://www.ibm.com/xmlns/prod/websphere/sis/”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:schemaLocation=“http://www.ibm.com/xmlns/prod/websphere/sis/../model/sis.xsd ”> <scheme name=“J2EE”managerClass=“com.ibm.websphere.sis.j2ee.J2EEScopeManager” /><schemename=“TRANSACTION”managerClass=“com.ibm.websphere.sis.transaction.TransactionScopeManager” /> <scheme name=“THREAD”managerClass=“com.ibm.websphere.sis.thread.ThreadScopeManager”weakReference=“true” /> </sis:scoping>

The establish module 304 may include a lifecycle module 406. Theestablish module 304 may trigger a class loader to load an instance ofan object and associated scoped resource 208 for access by a callingsoftware object 204 a-b. In one embodiment, the lifecycle module 406manages the scope lifecycle. A scope lifecycle begins with the creationof a scope, and ends with the destruction of the scope. Scope lifecycledescribes the period of time and events that occur during the existenceof a scope. Lifecycle events triggered by an action of a calling objectmay determine the lifecycle of a scope. In one embodiment, lifecycleevents include scopeCreated( ) and scopeDestroyed( ) commands issued bya caller. Alternatively the lifecycle events may be triggered by otheractions of a calling object including requests to access a scopedresource 208. In certain embodiments, the lifecycle module 406 mayinclude a scope event listener to recognize the lifecycle events. Thelifecycle of the scoped resource 208 may be determined by the lifecycleof the enclosing scope.

In one embodiment, the control module 306 includes a management module408. The management module 408 manages resources shared by the pluralityof independent objects according to policies defined in the specifiedscoping scheme 210. In one embodiment, the management module retrieves aslot for the scoped resource 208. In one embodiment, a slot is a storagespace dedicated to storage of variables and other data for the scopedresource 208. The management module 408 may control access to the scopedresource 208 by controlling access to information stored or to be storedin the slot. Additionally, the management module 408 may identify thescope of the calling software object 204 to determine allowableinteractions between the software object 204 and the scoped resource208.

For example, a software object 204 a may request access to a scopedresource 208. In one embodiment, the software object 204 a is a webapplication and the scoped resource 208 is data associated with a webservlet. The establish module 304 may establish access to the webservlet 208 by triggering a web servlet class loader to load an instanceof the web servlet 208 in accordance with scoping policies defined bythe specified scoping scheme 210. The control module 306 may thencontinue to control access by the web application 204 a to the webservlet 208 by limiting access to restricted attributes of the webservlet 208 and allowing access to shared attributes of the web servlet208. In such an example, attributes defined as local may be restricted,while other attributes may be shared.

In one embodiment, the management module 408 includes an access module410. The access module 410 accesses shared information in response to arequest from objects, each object 204 having a scope that satisfies thespecified scoping scheme 210. If the management module 408 does notdetermine that the scope of the calling object 204 satisfies thespecified scoping scheme 210, the access module 410 does not access thescoped resource 208 or information stored for the scoped resource in theshared data slot. If the management module 408 does approve accessbetween the object 204 and the scoped resource 208, the access modulemay store, modify, or retrieve shared data stored in the slot for eitherthe scoped resource 208 or the software object 204.

FIG. 5 illustrates one embodiment of a method 500 for scoped managementof software objects. In one embodiment, the method 500 starts 502 whenthe receive module 302 receives 504 a request to access a scopedresource 208 from a software object 204. The establish module 304 thenestablishes 506 access to the scoped resource 208. In one embodiment,access is established by instantiating an instance of the scopedresources 208 that inherits from a parent class having an associatedscope. The control module 306 then controls 508 access to the scopedresource and the method 500 ends. In one embodiment, the establishmodule 304 establishes 506 access according to a specified scopingscheme 210, and the control module 306 controls 308 access to the scopedresource 208 according to the specified scoping scheme 210.

FIG. 6 illustrates another embodiment of a method 600 for scopedmanagement of software objects. In one embodiment, the method 600 starts602 by checking 604 the scope service 206 for the desired scope. If thedesired scoping scheme 210 is not available 606, then the extend module404 is used to add 608 the desired scoping scheme 210 to the scopeservice 206. If the desired scheme is available 606, then the softwareobject 204 requests 610 access to the scoped resource 208. In oneembodiment, the software object 204 makes the request using theinterface module 402. Alternatively, the receive module 302 may receive612 the request for access to the scoped resource directly according toa predefined call using the scope service API.

When the request is received 612, a dertmination 613 is made whether thescoped resource 208 exists. If not, the lifecycle module 406 may detect614 a create scope event. The lifecycle module 406 may then create 616an instance of the scoped resource 208, since one does not alreadyexist. Alternatively, the software object 204 may request access toshared data of the scoped resource 208. If the scoped resource 208exists, a determination is made whether the scope of the callingsoftware object 204 and the scoped resource 208 are compatible 618, thenthe establish module 304 may establish 620 access to the scoped resource208. In one embodiment, the management module 408 may retrieve 622 aslot for shared data. The access module 410 may then access 624 shareddata stored in the slot. In an alternative embodiment, the softwareobject 204 may request 610 access directly to shared information storedin a storage slot associated with a scoped resource of compatible scope.In such an embodiment, the access module 410 may access 624 the shareddata directly for the software object 204.

If the scope of the software object 204 and the scoped resource 208 arenot compatible 618, the request is rejected. If a scope destroy eventoccurs 625, the lifecycle module 406 may detect 626 the destroy scopeevent and destroy 628 the scoped resource 208 and the method ends 630.The lifecycle module 406 may detect 626 a destroy scope event when thescoped object 208 is naturally or manually destroyed. The lifecyclemodule 406 then destroys 628 the scoped resource and the method 600 ends630.

FIG. 7 illustrates one example of a hierarchical scoping scheme 700. Thescope may be defined as an object such as a J2EE container 702. In suchan example, the J2EE components may access either an application 704, orapplication data 706 directly. An application 704 may access one or moremodules 708 or shared module data 710. Additionally, the modules 708 mayaccess EJBs 712 or shared EJB data 714. EJBs 712 may access one or moreattributes 716. An attribute is a named object within a context for agiven scope. For example, “EBJ1” may have multiple objects to be sharedin the “Component/ejb1” scope. These can be achieved by using attributeslike “Attribute1” and “Attribute2”. The attributes can be accessed usingthe name of the context. In such an example, the hierarchical scopingscheme 700 is designed to manage scope between the multiple hierarchicallayers of J2EE components, objects, and resources as described inrelation to FIG. 1.

For example a call written in Java to a J2EE counter object 702 mayinclude the following commands:

-   -   Map context=sharingManager.getContext(“J2EEPackaging”,        “Application”);    -   Integer counter=(Integer) context.get(“counter”);    -   counter=new Integer(counter.intValue( )+1);    -   context.put(“counter”, counter);        In such an example, a Map type variable context is assigned the        results of a call to a getContext( ) command of a sharing        manager. In this example, the sharing manager is one embodiment        of the management module 408. Then, an integer type variable        “counter” is assigned to the results of context.get( ) call. The        context.get( ) call represents access to the scoped resource 208        by the access module 410. Next, the value of the “counter”        variable is incremented. Then, the value of the original        “counter” variable is replaced by the incremented value.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

Beneficially, the scope service 206, the associated system, apparatus,and method reduce the number of scope related errors typically inherentto modular software design. Providing the API for the scoping servicemakes design and implementation of custom scoping schemes much simpler.Developers will not be required to manage the scope of each attribute,variable, object, and the like directly. The scoping service 206 mayhandle scoping issues independently. Use of the scoping service 206 mayreduce development time and increase software performance.

1. An apparatus for sharing and accessing data by scopes, the apparatus:comprising: a receive module configured to receive a request to access ascoped resource; an establish module configured to establish access tothe scoped resource accessible by a plurality of independent objectsbased on a specified scoping scheme; and a control module configured tocontrol access to the scoped resource in accordance with the specifiedscoping scheme.
 2. The apparatus of claim 1, further comprising aninterface module configured to provide an Application Program Interface(API) for associating a scope with a software object.
 3. The apparatusof claim 1, further comprising an extend module configured to add one ormore scoping schemes dynamically to the apparatus as a plug-in.
 4. Theapparatus of claim 1, further comprising pre-defined scoping schemesthat implement common scoping requirements.
 5. The apparatus of claim 1,wherein the specified scoping scheme comprises a hierarchical scopingscheme.
 6. The apparatus of claim 1, wherein the specified scopingscheme comprises a horizontal scoping scheme.
 7. The apparatus of claim1, wherein the establish module further comprises a lifecycle moduleconfigured to manage a scope lifecycle, wherein the lifecycle of thescope is determined by lifecycle events triggered by an action of acalling object.
 8. The apparatus of claim 1, wherein the control modulefurther comprises a management module to manage resources shared by theplurality of independent objects according to policies defined in thespecified scoping scheme.
 9. The apparatus of claim 8, wherein themanagement module further comprises an access module configured toaccess shared information in response to the request from objects, eachobject having a scope that satisfies the specified scoping scheme. 10.The apparatus of claim 1, wherein the software objects that share thescoped resource comprise compatible scopes.
 11. A system to for sharingand accessing data by scopes, the system comprising: an applicationserver configured to host one or more software objects; one or moresoftware objects configured to access a scoped resource; and a scopeservice configured to, receive a request to access a scoped resource,establish access to the scoped resource accessible by a plurality ofindependent objects based on a specified scoping scheme, and controlaccess to the scoped resource in accordance with the specified scopingscheme.
 12. The system of claim 11, wherein the scope service is furtherconfigured to provide an Application Program Interface (API) forassociating a scope with a software object.
 13. The system of claim 12,wherein the scope service is further configured to add one or morescoping schemes dynamically to the scope service as a plug-in.
 14. Thesystem of claim 13, wherein the scope service comprises pre-definedscoping schemes that implement common scoping requirements.
 15. Thesystem of claim 14, wherein the specified scoping scheme comprises ahierarchical scoping scheme.
 16. The system of claim 15, wherein thespecified scoping scheme comprises a horizontal scoping scheme.
 17. Thesystem of claim 16, wherein the scope service is further configured tomanage a scope lifecycle, wherein the lifecycle of the scope isdetermined by lifecycle events triggered by an action of a callingobject.
 18. The system of claim 17, wherein the scope service is furtherconfigured to manage resources shared by the plurality of independentobjects according to policies defined in the specified scoping scheme.19. The system of claim 18, wherein the scope service is furtherconfigured to access shared information in response to the request fromobjects, each having a scope that satisfies the specified scopingscheme.
 20. The system of claim 19, wherein the software objects thatshare the scoped resource comprise compatible scopes.
 21. A signalbearing medium tangibly embodying a program of machine-readableinstructions executable by a digital processing apparatus to performoperations for sharing and accessing data by scopes, the operationscomprising: an operation to receive a request to access a scopedresource; an operation to establish access to the scoped resourceaccessible by a plurality of independent objects based on a specifiedscoping scheme; and an operation to control access to the scopedresource in accordance with the specified scoping scheme.
 22. The signalbearing medium of claim 21, wherein the instructions further comprise anoperation to provide an Application Program Interface (API) forassociating a scope with a software object.
 23. The signal bearingmedium of claim 21, wherein the instructions further comprise anoperation to add one or more scoping schemes dynamically to a list ofscoping schemes as a plug-in.
 24. The signal bearing medium of claim 21,wherein the instructions further comprise an operation to includepre-defined scoping schemes that implement common scoping requirements.25. The signal bearing medium of claim 21, wherein the specified scopingscheme comprises a hierarchical scoping scheme.
 26. The signal bearingmedium of claim 21, wherein the specified scoping scheme comprises ahorizontal scoping scheme.
 27. The signal bearing medium of claim 21,wherein the instructions further comprise an operation to manage a scopelifecycle, wherein the lifecycle of the scope is determined by lifecycleevents triggered by an action of a calling object.
 28. The signalbearing medium of claim 21, wherein the instructions further comprise anoperation to manage resources shared by the plurality of independentobjects according to policies defined in the specified scoping scheme.29. The signal bearing medium of claim 21, wherein the instructionsfurther comprise an operation to access shared information in responseto the request from objects, each having a scope that satisfies thespecified scoping scheme.
 30. The signal bearing medium of claim 21,wherein the software objects that share the scoped resource comprisecompatible scopes.